Intent

This PR updates the infrastructure of the e2e testing facility while adding tests that mimic the existing coverage of the tests within test/vscode.

Resolves #2586

When this PR is merged, we can then merge in #2584, which will remove the old tests, which then will unblock #2569 and various other PRs which are failing CI.

Type of Change

• • Bug Fix
• • New Feature
• • Breaking Change
• • Documentation
• • Refactor
• • Tooling

Approach

As outlined within the related issue, there were a few tests implemented within the test/vscode project that needed to be replicated. These fell into a few buckets:

1. Confirming that errors and messages were properly displayed when a configuration was in error
   • For this, faulty configuration files with their deployment records were created and checked into the source. Test code was then written to select the associated deployment, and the UX was then verified to show the expected errors.
2. Ability to create a deployment for projects at different levels of a workspace
   • For this, I automated creating a deployment for a fastapi project in the base of the workspace loaded by the tests and deploying it. I then automated another deployment for a fastapi project located in a subdirectory of the workspace, and deployed it.
3. Ability to deploy
   • Along with the deployments verified within # 2 above, the existing tests include a deployment for a static hml file.

User Impact

No impact to users - this affects internal testing only.

Automated Tests

All the changes are related to automated tests.

Directions for Reviewers

Because of the addition of several projects into the testing content workspace, a review of the changes by walking through the commits individually is recommended.

You will see that I have extended the functionality available within the Cypress commands. The tests required both reading and writing of the config files, while also accepting errors to be present. To handle this, I have swapped out the toml library for a newer library (smol-toml) and have implemented reading & writing, as well as wildcard expansion for the toml files. I have also implemented a generic sequence that I've used to automate the creation of a deployment and publishing of the deployment.

I noticed that we are unable to automate the deployment of any non-python or static project, since the docker image used to host the VSCode server (and its related workspace environment), does not have a good way to install versions of R and Quarto into it. Without those interpreters being available for the publisher, it is impossible to create projects of the related content types. This has been captured within issue #2589, which will then open up our ability to implement automated deployments for all of the supported content types.

Checklist

• I have updated CHANGELOG.md to cover notable changes.